home *** CD-ROM | disk | FTP | other *** search
/ BBS in a Box 15 / BBS in a box XV-1.iso / Files / System 7 / A / Alias-tricks.txt.sit / alias-tricks.txt
Encoding:
Internet Message Format  |  1994-06-16  |  6.1 KB  |  [TEXT/MSWD]
  1. Date: Wed, 8 Jun 1994 13:52:38 +1000
  2. From: "Michael.Smith" <Michael.Smith@maths.anu.edu.au>
  3. Subject: Tricks for keeping aliases connected
  4.  
  5. Warning: I waffle on a bit in this message.
  6.  
  7. This a brief account of my recent experiences with aliases. Hopefully it
  8. will be of use to others. A simple trick allowed me to do a backup-restore
  9. of my hard disk with only a few aliases ending up detached (some because I
  10. forgot to unlock them before starting, others because they ended up
  11. pointing across the new partitions).
  12.  
  13.  
  14. How do aliases work?
  15. --------------------
  16.  
  17. As far as I know, an alias encodes its destination in two ways.  I won't go
  18. into too many details, since I have only educated guesses on precisely how
  19. it works, but experimentation can verify the following facts:
  20.  
  21. (1) Stored within the alias is a "pointer" to the location of the target on
  22. the disk --- when a file is created it is assigned a unique pointer which
  23. remains unchanged as the file is moved around, renamed and modified. If the
  24. file is deleted, this pointer becomes invalid.  If the pointer stored in
  25. the alias is valid then just follow the pointer to the target.
  26.  
  27. (2) Also stored in the alias is the last known path to the file. For
  28. example the stored path might be "HD:Documents:targfile" which means that
  29. when the alias was last resolved it was to a file called "targfile" in
  30. folder "Documents" on hard drive "HD".
  31.  
  32.  
  33. So when the system attempts to resolve an alias it first checks whether
  34. step (1) gives the target, and only if that fails does it then check step
  35. (2). If both fail, the alias cannot be resolved.
  36.  
  37. Bacause of step (1), you can create an alias to a file, and then move the
  38. file around, change the name of it and change the names of folders and
  39. drives that it is stored on. None of these operations changes the pointer
  40. to the file's information blocks. However, replacing a file by one with the
  41. same name does prevent step (1) from succeeding, but then step (2) comes to
  42. the rescue.
  43.  
  44.  
  45. Hassle free backup/restore
  46. --------------------------
  47.  
  48. What was I to do?  I had a 330MB hard drive with a single partition named
  49. "Centris650", and I wished to back it up, reformat and partition it into 3
  50. volumes, and then restore files into the 3 new partitions.
  51.  
  52. First I ran an alias checking program, which searches disks for all
  53. aliases, and tries to resolve each of them (AliasBoss, AliasZoo and
  54. FileBuddy all do this for you). This ensured all my aliases on "Centris650"
  55. had both their components (pointer and path) updated. This was important
  56. since I may have moved some around a while ago without resolving them
  57. since, so their paths would be incorrect, and the whole trick it to rely on
  58. the path component of the alias.
  59.  
  60. Then I backed up the disk into 2 different Stuffit archives, one for each
  61. of the intended volumes.
  62.  
  63. After reformatting and partitioning the drive, I restored the files into
  64. the 3 new volumes named "part1", "part2", and "part3".  But now every file
  65. was a new copy, and none of the pointers stored inside the aliases would
  66. point to their targets anymore. Moreover, an alias on one volume may now be
  67. for a file on another volume. All the paths stored in aliases start with
  68. the drive name "Centris650", so both resolving steps will(?) fail.
  69.  
  70. In three steps practically all aliases are fixed. Rename "part1" to
  71. "Centris650", and run the alias checking program. It finds all the aliases
  72. on all the drives, finds that none of the pointers work, and starts looking
  73. at the last known pathnames. All the targets on the first partition can now
  74. be resolved, since the first partition now has the old drive name.  In the
  75. process of successfully resolving by name, the pointers to files are
  76. updated as well, so when the name is changed back to "part1", all these
  77. fixed aliases remain valid.
  78.  
  79. Repeat this step for "part2" and "part3".
  80.  
  81.  
  82. Ammendment: It is possible that renaming the volumes is not necessary, but
  83. I didn't pay close enough attention while I was going through this process
  84. to know for sure.  A simple experiment seems to indicate that it is not
  85. necessary. Make a new folder called "XXX", and then an alias to it on the
  86. same volume. Delete the original. Rename the volume, and make a new folder
  87. named "XXX". The alias will find it, despite the fact the path is
  88. different.
  89.  
  90.  
  91. If the alias and the target are separated across partitions, the alias will
  92. not be fixed in this process. These must be fixed by hand (with the help of
  93. FileBuddy or something similar).
  94.  
  95. End result --- backup and restore completed with a minimum of broken
  96. aliases.  The only remaining problems are those file pointers that are
  97. stored in preferences files: eg your copy of Fetch or Anarchie can no
  98. longer find your "Download Folder", since when you set it the program
  99. stored the folder's pointer which no longer works bacause all files are new
  100. copies.
  101.  
  102.  
  103. Another mind numbingly simple tip
  104. ---------------------------------
  105.  
  106. I like to keep aliases in readily accessible places, and original programs
  107. in well organised places :-). Typically I have 4 or 5 aliases to an
  108. important or frequently used program.
  109.  
  110. Problem was, whenever I got an update to a program, there was a bit of
  111. bother replacing the old one by the new, because aliases usually broke.
  112.  
  113.  
  114. Now whenever I install a program, eg Fetch 2.1.2, I make sure that I store
  115. it in a folder that *does not* involve the version number. So I rename the
  116. folder to "Fetch folder", or something similar. I make sure the application
  117. does not involve the version number in its name, say "Fetch 2.1.2", since
  118. updates will then have different names. Rename it to simply "Fetch". Ignore
  119. the names of documentation files (indeed, hopefully they will be named
  120. "Fetch 2.1.2 docs" or something similar).  Now I make all the aliases I
  121. want of the application.
  122.  
  123. When I get a copy of Fetch 3.0, updating is now easy. Rename the folder it
  124. is in to "Fetch folder", and make sure the application is called simply
  125. "Fetch".  Replace the old folder by the new one. All aliases will continue
  126. working.
  127.  
  128.  
  129. Cheers,
  130. Michael.
  131.  
  132. ---------------------------------/|-|--|-|--|--Michael-Smith-------------------
  133.  Michael.Smith@maths.anu.edu.au /-| |\ | |  |  Mathematics (CMA)
  134. -------------------------------/--|-|-\|-|_/|--Australian-National-University--
  135.  
  136. http://pell.anu.edu.au/~smith/Michael_Smith.html
  137.  
  138.  
  139.